Hi,

This is a known bug that we already have an internally build that fixed the problem. We will PM you the download location shortly.

Thanks!

Hi,

The first run is always much slower as it needs to initialize the “engine”. The subsequent run should be not be as long. When you have parallel thread trying to perform conversions, multiple engines will be created. As it shows in both of your test, the subsequent runs are significantly faster than the first run. This is normal for our converter. The way you start the conversion aggravated this a lot because you are trying to start 10 concurrent conversions exactly at the same time. When we "start up" the engine, we will check the status of existing engines. This is very quick if the engine is already started and running ---- however it will lock for a while when the engine is still in the process of being initialized.

The time it takes to "fire up" should not be much of a concern in a real life scenario. In a real life scenario you probably would never have 10 working thread all be created and started at exactly the same time and start conversion. For a server application such as Web application, the threads would be started depending on user request, which comes in randomly. Besides, as long as the “engines” are initialized, the converter will run much smoother and faster. If the slow initializing time still concerns you, you can create an idle thread and call ConvertHtml with blank string to initialize a “spare engine” first. That should be very quick and that “spare engine” will take over whenever all other engines are busy.

Thanks

Hi,

We have numerous customers using our product in production server environment and it scales just fine. What you are trying to do is pushing it over the limits to unnecessarily stress it. There are a lot of reasons why it may slow down significantly when you push it over a certain limits. For example, we will swap out a lot of data from memory to disk when we detected that your memory is running low. This will slow down things significantly because then basically everything is run on disk. This is not a disadvantage ---- the opposite is to throw a out of memory exception and crash your application. This is just one of the extra things we do to make sure our product runs smoothly in a server environment and it helps to handle spikes. Your server does not have unlimited power. So I would recommend you to find out the best performance point and try to keep load below that point.

Thanks!

Hi,

"Scale" does not mean that it is always the fastest. Scalability is more about stability under heavy load and ability to scale up along with the network (for example, when you add more servers).

There are many important factors when it comes to a product like EO.Pdf. Performance is just one of them. In addition to the performance, the quality of the output PDF file and the stability of the product are even more important. We do a lot of extra work on these two. For example, we try to render every drawing in vector format, while many other vendors simply render it as bitmap. So a CSS3 round corner in our PDF will be vector format and you can zoom in infinitely, that means much better quality when printing out. We also run our core conversion code in a separate worker process instead of inside your process. We have additional code that monitors the health of the worker process and if it sees any problems, it will try to terminate and restart it. All those happen transparently to you and the result is a more stable and reliable product. However there is a trade off with everything ----- on a fixed hardware, doing more on one side means we have less room on the other side. For our product, the quality of the output file and the stability of the product definitely have a higher priority than pure performance. So we definitely do not think it’s worth it to just pursue performance alone as the only indicator.

In additional to those, there are also a lot of additional feature we put out so that our users find very useful. The "singleton" design you mentioned is one of them. While the programming interface appears to be a singleton design, internally it is actually not. To answer your question about "how to run conversion in parallel with different settings" ---- you just use it the same way as you do in a single thread without worrying about anything at all. A different set of settings are automatically maintained and isolated for a different thread. So if you have two conversions running in parallel in two different thread, you just set the settings in your thread and they will not have anything to do with each other. We are not the only one does things this way ---- ASP.NET does things this way too (ever wondering whether you need to lock on session variables?). This is just one of the samples that we try to make it as easy as possible to you. We also have additional features such as returning you the HTML DOM tree so that you will be able to use it to find the location of any DHTML element and add anything else with our ACM interface. All those are nice features but again everything is a trade off. This is similar to full loaded SVU and a bare bone minimum car. If the only thing you are concerned about is gas mileage, then you should definitely go to a small car because a full loaded SVU burns more gas and it is not possible for the SVU to match the gas mileage of a small car. Most of our customers think what we offer is worth the trade off, but ultimately every customer is different and there is no single size that fits all. So in this case, it really depends on your priority. We cannot just cut all the extra features we offer off to match somebody else's performance.

Also we believe some of the performance test you do is far from typical in real life scenario. For example, the test you did when you start all 10 conversions at the same time almost never happen in real life scenario so it definitely would not be a priority for us to "solve it". Our ultimate goal is to provide our customers something very useful in their real life deployment, not to produces something that just has the highest score in every imaginable test. The overall value we can offer to our customer is definitely much more important than one or two test alone.

Based on all those reasons, we do not believe the "performance issue" you reported is something that needs to be addressed ---- don’t get us wrong, it’s not that we do not believe performance is important --- we have in fact done extensive performance test and optimization so we actually do not believe there is too much room left. The real reason behind our position it’s because performance is not the only concern and there are a whole load of things we have to balance very carefully. How well we balance has a very direct impact on the product quality and we fully understand that no every customer agrees with our balance point. But most of them do agree with us, and that’s precisely why we are the most popular HTML to PDF converter out there.

Hope this give you a good idea of the rationale behind our position. Please feel free to let us know if you have more questions.

Thanks

Hi,

You have to trust us on this ---- we have already done extensive performance testing and optimization before on this product. We feel what you are expecting is a significant performance boost which is not a realistic expectation at this stage. It's like the car currently has a mileage of 30 and you want 15. That's simply not going to happen without changing this car into a totally different type of car. Also when it comes to performance, it is not like a bug that you can trace to a single line of code and fix it right away. Any significant performance boost has to be the result of a system wide optimization because every little bit counts. To be very frank with you, we do not believe that's something we should do for a stable product since that would risk breaking loose a lot of things with very little to gain. As to many things you mentioned, such as significant performance drop after a certain load, we know exactly why it happens and we have already explained it to you ----- you are hitting the upper limits and you should try to stay below that limit. We could risk everything to raise the limit to another 5% while you probably is expecting at least 50%, while after that 5% boost we might have broke something else elsewhere and in the end you will have a newer version 5% faster but 20% less stable. Obviously neither you nor us want that.

I understand you have a valid concern but at the same time I want you to believe we know what we are doing and we are quite sure you are after a dead end here. So I think you should give up on this. If the performance does not meet your need, then I would recommend you go with another product ---- I am not trying to push you away, but while I believe we have the best value, we have our advantages and other vendors have theirs, and in the end it’s what matters to you most that’s important. When we sell a product to you we wanted it to be truly usefully to you and if that does not stand true, the product may not be the best fit for you. We always work very hard try to give you the best we have and in this case you are already getting the best here.

In your case, the only suggestion I can make is to try to randomize your conversion task ---- such as adding a random time delay before starting each thread, and convert different randomly documents in each thread. This way each thread won’t all be doing exactly the same thing at the same time, and that might allow you to handle a little bit more load.

Thanks!

By the way - 15 days ago EO.PDF (a "stable product") didn't event work in a multi-threaded environment. So you can't claim this is an area that is well tested for your component.

Please investigate this problem.

In our evaluation of Eo.Pdf and Eov.Pdf, average single-threaded render time for 100 Pdfs was: 1.12 seconds for Eo.Pdf, and 4.34 seconds for Eov.Pdf.