Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

SSD = faster PDFs?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    SSD = faster PDFs?

    We're looking for *anything* that will speed up PDF production and delivery.

    Has anyone compared an SSD to a standard HD to see if that makes any difference?

    I'm on cloud servers, it wouldn't even be hard to add a RAM drive if there was a way to use that for the PDFs.
    -Steve
    sigpic

    #2
    Re: SSD = faster PDFs?

    Steve,
    We have 4 SSD drives in our server and they make a huge difference with disk reading and writing. In our tests, if your bottleneck is in reading or writing the pdf files, you can expect the disk processing to be about 6-8 times faster with SSD drives.

    We’ve had such good success with them that we are now converting our workstations to use them as well.

    Hope this helps...

    Comment


      #3
      Re: SSD = faster PDFs?

      If you any questions about I/O - SSDs will essentially eliminate that variable - it does sort of depend on the kind of SSDs - those vary too, but most enterprise level SSDs will be fantastic. We are working towards moving to almost all SSDs for our clients. In the US this has started already. We see absolutely no bottlenecks on the disk side with SSD.

      Next phase - it's NVMe, we are building some new gear where the caching and tier 1 storage will be on NVMe, then SSD for tier 2-3, followed by tier 4-5 HDDs for slower, read/write/snapshot repos.

      There's definitely no concern with I/O with NVMe, but rather can your network infrastructure actually handle that amount of throughput! It's like going from a 24 lane Autobahn to a 2 lane highway :)

      Comment


        #4
        Re: SSD = faster PDFs?

        Steve, have you done any time studies to see where the bottlenecks are?

        At ENEFEN we did a project to speed up printing of pdfs and ended up doing a bunch of things, but the three that helped the most were:

        If you are pulling data from several different tables like we were, it helped a lot to use a stored procedure to build a single temporary memory engine table, sorted in print order, that was then used to print the report. Transfer that table to the server that contains the alpha print engine.

        Our pdf's were a combination of individual pdf's that were appended together. For that, Jerry B. suggested pdf_append_list() that loads them into memory and does the append there. Much faster and more trouble free than pdf_append()

        Our reports contained a lot of boiler plate, pictures and drawings, so we made a lot of use of printHTML() to print areas that were already formatted as variables in memory with alpha.

        I would expect the SSD's to help but, like Nate, I'd worry about the network speed throttling that speed back.
        Pat Bremkamp
        MindKicks Consulting

        Comment


          #5
          Re: SSD = faster PDFs?

          Thanks gents.

          Looking at doing this on one server tomorrow. I wonder:

          Right now I simply have a C:\ drive with everything on it.

          So, I add an SSD as the D:\ drive and move the webroot to that.

          But, is that sufficient? Does any / a lot of the work rendering the PDFs get done on the C drive still? How to insure the PDF work gets done on the SSD?

          For obvious reasons I really don't want to go through a whole new construction of a new SSD boot drive.
          -Steve
          sigpic

          Comment


            #6
            Re: SSD = faster PDFs?

            I use Alpha's runtime to generate PDF docs for patient medical records that can be, at times, hundreds of pages in length. Because of the potential for these PDFs to be quite large the user returns to the app sometime later to download it. How are you handling your PDF creation and delivery?

            When my process runs a ton of temp files are created in C:\Users\Administrator\AppData\Local\Temp\AlphaAnywhere\p_4892. Something else to consider: Does a SSD even matter when these PDF's are being built? Wouldn't that be a function of processor and memory speed?
            Mike Brown - Contact Me
            Programmatic Technologies, LLC
            Programmatic-Technologies.com
            Independent Developer & Consultant​​

            Comment


              #7
              Re: SSD = faster PDFs?

              I'm not sure where the PDF production bottleneck is, sure wish I knew.

              Looks to me that the process to switch to an SSD on the cloud is this:

              1. Create an image of the existing standard drive
              2. Create a new SSD drive using that image
              3. Detach existing drive, attach the new SSD drive.

              I have 1 & 2 done already but need to wait until later tomorrow for Step3.

              I think this solves my question of how to be sure the PDF work is done on the SSD.

              SSD drives perform better with more CPUs. Google Cloud's examples often use 8 or 32 CPUs. We're running 4 on the server, and I don't want an email from Alpha telling me I've broken my license agreement by adding more CPUs.

              As for later delivery, yes, we have some of that in place but need to formalize, centralize and build that out, and figure out how we can "know" that some reports can be delivered immediately to the browser, and others stored for download later on. Variables include user-selected date ranges. One report spanning one day is going to be just fine for immediate delivery. But if the user selects 10 days, maybe store for later. And date range is just one of several variables.

              So, we're throwing more/better hardware at this to begin with. Not a total solution, but hopefully a part of a solution. And it may make more reports available immediately to the user rather than stored for later download.
              -Steve
              sigpic

              Comment


                #8
                Re: SSD = faster PDFs?

                Yes I switched to SSD basically for that reason alone. Makes it almost instant.

                Comment


                  #9
                  Re: SSD = faster PDFs?

                  Originally posted by Pat Bremkamp View Post
                  Steve, have you done any time studies to see where the bottlenecks are?

                  At ENEFEN we did a project to speed up printing of pdfs and ended up doing a bunch of things, but the three that helped the most were:

                  If you are pulling data from several different tables like we were, it helped a lot to use a stored procedure to build a single temporary memory engine table, sorted in print order, that was then used to print the report. Transfer that table to the server that contains the alpha print engine.

                  Our pdf's were a combination of individual pdf's that were appended together. For that, Jerry B. suggested pdf_append_list() that loads them into memory and does the append there. Much faster and more trouble free than pdf_append()

                  Our reports contained a lot of boiler plate, pictures and drawings, so we made a lot of use of printHTML() to print areas that were already formatted as variables in memory with alpha.

                  I would expect the SSD's to help but, like Nate, I'd worry about the network speed throttling that speed back.

                  Thanks for the info Pat. I'm wondering if you could give some more details on the stored procedure process you mentioned. How does one go about doing a report with a stored procedure?

                  Thanks,
                  Mike Reed
                  Phoenix, AZ

                  Comment


                    #10
                    Re: SSD = faster PDFs?

                    Well, we don't have extensive testing. One comparison is all in fact.

                    I have two web servers, about identical so now one has the new SSD and the other a standard HD. I used localhost to compare the creation/delivery of a 200 page PDF so that load balancers, etc. are not part of the equation.

                    There was no difference in delivery times. Not even one second difference.

                    Pat's right that stored procedures and everything else you can do to take the processing off of Alpha is very helpful. Right now I'm not sure switching to SSD does a whole lot for PDF delivery though.
                    -Steve
                    sigpic

                    Comment


                      #11
                      Re: SSD = faster PDFs?

                      Our challenge was to create a 20 to 30 page report that was made up from 8 to 10 individual pdfs. Some of the pdf's included 30 to 50 images and some were B sized drawings built on the fly and we needed a table of contents.
                      We are using MariaDB and that includes a memory engine that builds a table in memory rather than on the hard drive. Memory engines are emptied whenever the server is restarted, but in this case the data is only needed until the report finishes, so that is not a problem. So, we stratified speed from fastest to slowest and got
                      memory
                      reading an individual table (only one start and stop, the slowest part of table operations). This is also faster if that table is dedicated to the print operation so it is not subject to locks from other users.
                      stored procedures in the database engine when there are multiple tables to read and write. The database engine is multi-threaded. For example, we reduced the time to create a table from 5 seconds to 1/2 second.
                      Xbasic loaded into memory in an aex or Xbasic module using require()
                      Xbasic reading and writing to a table
                      internal network
                      print engine
                      internet

                      So, the idea is to push as much processing as possible up this list. We created a single memory table, sorted in order and used a stored procedure to populate the table from the multiple source tables. We compressed the images and stored them on the same server as Alpha prior to printing. We used an Xbasic module where possible for the processing.

                      When we started, we were using alerts to the user so they would know the program was not locked up. When we finished, the alerts were not needed because the whole process was only a couple seconds.
                      Pat Bremkamp
                      MindKicks Consulting

                      Comment


                        #12
                        Re: SSD = faster PDFs?

                        Hey Steve, do the reports need to be live data or is a snapshot from a few hours ago good enough?
                        Chad Brown

                        Comment


                          #13
                          Re: SSD = faster PDFs?

                          They vary Chad. I'm assembling one central/monster reporting center. Couldn't tell you the eventual number of reports - well over 200 I think so lots of differing needs.
                          -Steve
                          sigpic

                          Comment


                            #14
                            Re: SSD = faster PDFs?

                            Steve I have a few reports that are based off of previous days sales and can go back as far as a few years.
                            The sql views that they worked of were massive and took a few minutes to build the pdf files.
                            I now run a scheduled task in Navicat to export the view to excel file then import it back in as a flat new table.
                            That report use to take up to 7 minutes to produce is less than 7 seconds now.
                            Just a thought for items that dont need to be live.
                            Its sort of what Pat does with temporary tables.
                            As a side note if you can get a server to run off of the new m.2 drives it will be even faster.
                            They are up to 10x faster than SSD.
                            Chad Brown

                            Comment


                              #15
                              Re: SSD = faster PDFs?

                              based on your posts from march 7, did you improve performance?

                              Comment

                              Working...
                              X